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The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1 986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UH-Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology needed for JSC’s main missions, including 
administrative, engineering and science responsibilities. JSC agreed and entered into 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1 986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9-16, computing and educational facilities are shared 
by the two institutions to conduct the research. 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/JSC, and other research organizations. Within UH-Clear 
Lake, the mission is being implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involved via the “gateway” concept. UH-Clear 
Lake establishes relationships with other universities and research organizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICIS is to find the best match of sponsors, researchers and 
research objectives to advance knowledge in the computing and information 
sciences. Working jointly with NASA/ JSC, RICIS advises on research needs, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NASA/ JSC. 
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Discrete Mathematics, Formal Methods, the Z Schema 
and the Software Life Cycle. 

This paper is submitted in partial fulfilment of RICIS Task 
SE.26. The author and principal investigator is Dr. Rod Bown, 
University of Houston - Clear Lake. 

I . Introduction 

This paper discusses the proper role and scope for the use of 
discrete mathematics and formal methods to in support of re- 
engineering of security and integrity components within deployed 
computer systems. It is proposed that the Z (pronounced "Zed") 
schema can be used as the specification language to capture the 
precise definition of system and component interfaces. This can 
be accomplished an object oriented development paradigm. One 
such effort is presented in [WOOD90]. 

II. Requirements 

The software engineering life cycle starts with a set of 
requirements written in precise language using the terminology of 
the customer's application domain. The requirements document 
serves as the legal technical interface between the customer and 
vendor. A third party judge should be able to use the 
requirements document to measure success or failure of the 
delivered system. For this reason a requirement is a statement 
of intent written in such a way that a metric can be used to 
measure success or failure of the developed system. 

Requirements are captured by system modeling techniques which 
include viewpoint analysis and check lists. Controlled 
Requirements Expression (CORE) is one methodology that supports 
the gathering and analysis of requirements. Requirements can be 
supported by diagrams and tables that are understood by the 
customer and a potential third party judge. The customer should 
be able to understand all requirements without special training. 

In a sense, the requirements document is the specification for 
the set of tests that will be performed to validate the product. 
The requirements document may contain a glossary that provides 
precise definitions for all unique terms related to the 
application domain. 

Each design module or activity will be a response to a 
requirement. In accordance with a specified standard, numerical 
labels are attached to each requirement and all resulting design 
activities. This will allow a software management tool to 
automatically provide forward and backward audit trails. 
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A rationale subparagraph should be contained in each traceable 
requirement. This will provide guidance during the design, 
maintenance and enhancement phases of the life cycle. The 
rationale serves two purposes. One purpose is to provide the 
context in which the requirement was stated in order to restrict 
undesirable side effects that could result from modifications to 
implemented modules. The second purpose is to act as a forcing 
function for future modifications. If the rationale has changed, 
the implementation may need modification. 

There should be a limited amount of statements related to the 
implementation issues of the delivered system. Requirements that 
constrain the design alternatives are usually related to 
industrial standards for hardware and software interfaces. 

This discussion has been provided to substantiate the argument 
that requirements will continue to be written in precise natural 
language such as English. There are two customers (readers) for 
the requirements document: the customer and the design team. It 

is the design team that will transform the precise English, 
diagrams, and tables into a formal specification document. 

Ill* Specifications 

The design team is responsible to transform the external 
requirements document into an internal system specification 
document. The specification document should use precise 
terminology that is based on mathematical, physical, and computer 
domains. The terminology of this document need not be understood 
by unsophisticated readers. An audit trail is supported by an 
assertion that a particular specification is the formal 
presentation of a requirement. 

As a special note, different terms appear in the literature. One 
author uses the terminology of requirements definition and 
requirements specification [SOMM89]. The requirements definition 
is a natural language description of the requirements. The 
requirements specification is a more formal requirements 
description. 

IV. Formal Methods 

Computer systems that control life and property are becoming 
common place within society. History indicates that when a 
technology enters common usage, society will demand assurance 
that the design was completed in accordance with accepted 
mathematical and physical models and good design practices 
supported by standards. In a like manner software customers 
(society) will insist that the design of software systems must be 
based on mathematical and physical models that are supported by 
some level of formal proof and/or history of proven acceptance. 
This will include the use of appropriate standards. During a 
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1989 visit to UHCL, Dr. John McHugh presented this point in an 
elegant discussion of the software engineering failure that 
resulted in the Internet worm incident [McHU89]. 

Formal or precise methods are becoming a requirement for the 
development of safety critical software. The term safety 
critical includes the security and integrity issues of software 
systems. Woodcock and Loomes in their book define formal methods 
as the class of formal systems which have been designed to be 
useful specially for the development of complex systems, together 
with the associated manuals and courses which give rise to 
guidelines for the formal system's use on real problems [WOOD89]. 
No one formal system is ever likely to be suitable for describing 
and analyzing all aspects of a complex system. A formal method is 
not the method which a system designer might choose to use when 
developing a system, but one of the tools that a designer might wish 
to make use of during the process. 

V. Z Schema and a Small Example 

The following discussion has been extracted from [WOOD89] and 
modified for this document. In a specification, one can see a 
pattern occurring over and over again: a piece of mathematical 

structure which describes some constrained variables. The 
introduction of variables under some constraint is called a 
schema. One schema that shows promise for the specification of 
Ada programs is Z (pronounced "Zed") . 

This section will describe part of a configuration manager that 
maintains modules written in a language such as Ada. Modules 
have names drawn from the set Name. For this discussion regard 
the parameter Name as a parameter of the specification. Such a 
parameter is called a given set, and is regarded as a primitive 
type. There is another given set Body of all (syntactically 
correct) module bodies. 

A module may import definitions (of program functions, procedure, 
types, etc.) from other modules. For this example consider three 
program modules. The module Application needs to write a string of 
characters to the screen. Since this is such a common thing to 
do, there is a standard module that deals with "transput" and 
contains the definition of writestring. Application imports the 
definition from Transput. Transput in turn implements writestring in 
terms of another lower-level routine called putchar, which is 
imported from the first module, ScrtenHandler . The reader should 
see the analog to the predefined TEXT_IO package in Ada. 

At this level of abstraction the text of a module consists of a 
triple: the name of the module; a set of names of imported 
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modules; and the body of the module. A module should not import 
itself. 

Text : P {Name x (P Same) x Body ) 

Text = {n : Name, s : P Name, p : Body | n ^ s • {n, s, p ) } 

The three concrete examples of Text are 

t t * (ScreenHandler, { } , 
module ScreenHandler 

begin proo putchar . . . end) 

t 2 = (Transput, {ScreenHandler}, 

module Transput with ScreenHandler 

begin proo writestring . . . putchar . . . end) 

tj = (Application, (Transput), 

module Application with Transput 

begin proo . . . writestring . . . end) 

This can be seen in fragment form as 

t 1 module ScreenHandler 
begin 

proo putchar 
• • • 

end 

t 2 module Transput with ScreenHandler 
begin 

proo writestring 
. . . putchar . . . 

end 

t 3 module Application with Transput 
begin 

. . . writestring . . . 

end 

These relations cam be described using discrete mathematics. For 
this example a text imports those modules named in its set of 
imports : 


j imports . : Text Name 
( n\,s,p ) imports ni € s 
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The program fragments provide the following facts about imports: 

*i £ dom imports 
t2 imports ScreenHandler 
h imports Transput 


Another relationship can be built on imports, but it is a relation 
on Texts : one text needs another if it imports the second's name: 

.needs . : Text ~ Text 

i n \,Si,pi) needs (ni,S2,pi) o («i, Ji,Pi) imports n 2 


The set of module texts can be divided into "compatible" modules. 
One can regard the name of a module and the set of module names 
that it imports as constituting the "signature" of a module Two 
modules are compatible if they share the same signature: 

I jcompat . : Text «— Text 


(/fi.Si.Pi) compat (n 2l s 2 ,p 2 ) = *2 A Si = s 2 


The specification of the configuration manager is continued by 
describing its state . The state consists of those data structures 
that are maintained by the system; the operations in the system 
5 h f S f data structures and therefore change the state. 
data types are used to build a theory of the state 
Y?™ Wl11 SjY® as models suitable realizations in a programming 
langu a ge. This example will show how the state is initialized ^ 
and how the values of the state before and after operations are 


The state contains two components: a store of Texts and a relation 

which describes when one stored text is a version which is a 
successor for another stored text: 

store : P Text 
.sue. : Text «— Text 


lult Sir e constrained ln the following ways. A module 

an un£ri;Lh?« S? successor of itself, for that would introduce 

i°° P When s ® ar P hln 9 for the end of the chain. 
Tnus ths transitive closure of sue is lrrsflcxivB! 


sue 1 € Irreflexive[Text\ 
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where Imflexive[X] is the set of all irreflexive relations on X: 


Irreflexive[X] = {/? : X ~ X | (-* 3x : X • x R jc)} 

If text tj is the successor of another t 3 , then they must be 
compatible, that is sue is merely a subset of compat: 


sue C compat 

All the nominated modules that have, or are themselves, 
successors must reside in the store: 

sue C store x store 


store and sue constitute a proper state of the configuration 
manager whenever they satisfy these three constraints: 

sue 1 € lrreflexive[Text\ 
sue C compat 
sue C store x store 


Discrete mathematics is sufficiently powerful to describe many 
aspects of software systems. However, its application to large 
scale specifications soon results in unwieldy descriptions that 
are difficult to follow. It isn't the language that is at fault, 
but rather the human need to comprehend just a small amount of 
information at a time. One of the most basic things that can be 
done to improve a specification is to identify and name commonly 
used concepts and factor them out from the rest of the 
description of a system. Comments on mathematical notation are 
presented in the Appendix. 

In specifications, a pattern occurs over and over again. This is 
a piece of mathematical structun which describes some constrained 
variables. The introduction of variables under some constraint 
is called a schema . The Z schema uses a template that provides 
for the schema, a declaration of some variables, and a predicate 
constraining their values. 

_ Name 

! declarationpart 


predicate 
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When there is a change in state, the convention is to "decorate 
the names of the "after" variable with a dash. 


The configuration manager has three predicates that characterize 
its state, which together form the state invariant . The state 
invariant, together with the declarations of store and sue form a 
schema which is called ConfigMan. This package of definitions is 
a mathematical structure that describes all legal values of the 
state of the configuration manager: 

_ ConfigMan 

store : P Text 
juc_ : Text ~ Text 

sue 1 € Irrejlexive{ Text) 
sue C compat 
sue C store x store 


This schema is equivalent to that previously presented. Each line 
of the predicate forms a conjunct with the other lines. 

The initial state of the configuration manager is an empty store 
and an empty successor relation. The initialization of a system 
can be regarded as a peculiar kind of operation that creates a 
state out of nothing; there in no before state, simply an after 
state, with its variables decorated with a • . The decoration * 
is used for labelling the final state of an operation. 

_ InitConfigMan 

store' : P Text 
_suc f _ : Text *-> Text 

store' = {} 
sue' = {} 


There is only one state of the configuration manager that 
satisfies this description. There must be at least one, 
otherwise we could not implement the system. 

If the name of the schema is decorated with ' , it is understood 
to mean the same mathematical structure, but with component names 
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so decorated. For the configuration Manager, the state after an 
operation is described by CoqfigMam’. In detail this means: 

ConfigMan' 

jud _ : Text <— Text 
store 1 : P Text 

sud C store 1 x store* 

sud C compat 

sud 1 € /rre>fe.r/ve[7V;«] 


The notation introduced has increased our ability to capture 
specification of software systems within a schema. The Z schema 
provides for schema to include previous schemes. This can be 
seen in the simple example of a hopper which has been extracted 
from [SOMM89 ] . The specification of a Hopper includes the 
schemas for Container and Indicator in its declarative part. The 
expanded specification for the Hopper does not use the previous 
schemas. The reader can see that the expanded specification 
includes all of the details which clutters the presentation. 
Additional schemas are included that exhibit the filling 
operation of the hopper. 

In this paper the discrete mathematics and Z templates have been 
extracted from the cited references. This writer assumes that z 
schema editors and proof tools will be available in the 
foreseeable future. At the present time, it is not worth the 
effort to use Word Perfect to create the mathematics and 
templates. 

V I « Case Studies 


The September 1990 issue of the IEEE Software magazine contained 
two articles that presented discussions of successful 
applications of the Z schema. The design of an X-ray machine was 
discussed by [SPIV90]. The design of an oscilloscope was 
presented by [DELI90]. 

Of special interest to NASA is the case study discussed in 
[JACK90] . Jacky has reported on the Clinical Cyclotron Therapy 
System at the University of Washington. This is a cyclotron and 
radiation therapy facility that provides cancer treatments with 
neutrons, production of medical isotopes, and physics 
experiments. The control system handles over one thousand input 
and output signals. 


The designs are attempting to achieve high reliability and safety 
by applying rigorous software development and quality control 
practices. They have been intrigued by the possibility that 
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formal software development techniques might result in additional 
improvements in reliability and safety beyond those achieved 
through traditional practices, namely, English like 
specifications, subjective design and code reviews, and lots of 
testing. 

Other important design goals are improved maintainability and 
adaptability to future hardware and software modification. This 
appears to be a direct analogy to space shuttle enhancement and 
space station design goals. 

The project is apparently the first application of formal methods 
to an accelerator control system. In the literature a few 
reports describe acceptance testing from the customer's point of 
view; none discuss design internals nor development practices. A 
typical presentation emphasizes hardware organization. 

Discussion of software is limited to informal treatment. There 
is little interest in development methodology; the very concept 
of "specification" is practically absent from this literature. 

Jacky states that the best known natations are Z and VDM but that 
Z appears to be gathering more published tutorials and case 
studies. The author has observed that the distinguishing feature 
of Z is the schema calculus , which provides a convenient way to 
build up large specifications from textually separate components 
called schemas. In Z, specifications consist of two principle 
components: descriptions of abstract data structures that model 

the internal state, and definitions of operations that manipulate 
the state. For NASA this is the key observation. The schemas 
provide a precise modeling technique to support object oriented 
design of the software. 

The author is not an experienced Z user. He has provided samples 
that are intended to show how some of the control system 
requirements might be expressed in the Z style, and to reveal 
some of the difficulties encountered by self-taught 
practitioners . 

The article provides Z schemata examples listed below: 

Names and definitions for control parameters. 

Units and conversion formulae. 

Example of schema inclusion. - MACROS 
Constraints on values. 

The schemata cited above provide documentation for the database. 

Z schemata are shown for display (Xi schema - values are 
unchanged) 

Delta schema, operation changes the state. 

A software interlock. 

Error messages 
timing constraints. 
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There are difficulties using Z to represent interdependent 
collections of serial and parallel operations, event-driven 
operations, and concurrency. Note: the LOTOS technique has 

constructs that support modelling of concurrent structures. 

LOTOS is discussed in a separate report as part of this task. 

Jacky reports that writing comprehensive formal specifications is 
feasible. An unsolved problem is the proper notation for 
concurency. The author chose Petri nets for concurrency. The 
specifications for event driven operations were represented by 
the Software Cost Reduction (SCR) notation [HENI80]. SPECIAL 
NOTE: The SCR or A7 Notation was developed by David Parnas and 

colleagues at the Naval Research Laboratory during the late 
1970's. During 1989, the SCR technique was used to express the 
software specifications in support of the safety verification 
effort for the Darlington Nuclear Power plant in Ontario, Canada 
[JOAN90] . A recent article by Parnas in the Communications of 
the ACM cites the use of SCR to safety critical systems [PARN90] . 

Narayana and Dharap have reported on the successful application 
of the Z schema to a graphical interface [NARA90A] [NARA90B] . 
Dialog systems are servers for an interface. They are like 
operating systems in the concepts they provide. The Z notation 
was used for the formal design of the system. The authors 
provide Z schemata for INTERACTOR objects, DIALOG, SCREEN, 
DISPLAY, PHYSICAL_MOUSE and more. 

V II t Qblect; Oriented Design and Reusability 

The Z schema provides a concise mathematical notation that can be 
used to support object oriented design with reusable components. 
Objects can be decomposed into smaller objects. This supports a 
top down divide and conquer design procedure. In addition, large 
objects can be composed of small objects. If the Z schema was 
used to design the reliable component, the new design will 
inherit the associated mathematical verification of the 
component. The Z schema offers an opportunity to reuse reliable 
software code and its associated verified design specification to 
compose reliable systems. 

This document has been written to propose that the object should 
be chosen as the viewpoint for a system component. Objects can 
be decomposed into smaller objects in accordance with a divide 
and conquer design paradigm. In addition large objects can be 
composed from smaller reliable objects. Objects can provide a 
consistent viewpoint across the many phases of specification and 
design. The Z schema can support the design and reuse of an 
object. Objects can be used to define reliable and safety 
critical components and subsystems. Systems can be composed of 
reliable subsystems. The use of formal methods and the Z schema 
will provide the assurance of reliability that will be demanded 
by society for safety critical systems. 
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Conclusions and Recommendations 


This writer believes that formal methods will be required to 
specify trusted systems. In the immediate future, software 
designers should apply discrete mathematics by hand using a 
proper schema such as Z. This will provide a period of training 
and application experience for the designers. As the use of 
formal methods is expanded, it is assumed that tool support will 
be provided for common schemas. Z editors and proof tools will 
become available. The reuse of software will be enhanced by the 
use of foraal methods to specify reliable components within an 
object oriented design paradigm. 

I2L_ Befeyence Material and Educational support 

Discrete mathematics is the foundation for all formal methods. 

The mathematics takes the form of propositional and predicate 
calculus, set theory, relations, functions, and sequences. This 
writer has found that the 1989 book by Woodcock and Loomes is the 
easiest to read [WOODS*]. The authors have chosen thTz sciema 

exchanged" taX tD exhlblt the fornal specification of a telephone 

Ince's book was published in the United States in 1988 riNCE88i 
to take * gentle approach to the subject of foraa? 1 ' 
peci ficat ion. The Z schema is chosen to represent the formal 

1 ibrary S * * Z SChema fonnal specification is shown for a 

The 1981 book by Gries is still valid [GRIE811. it is one of the 
required textbooks listed for the Software Engineering Institute 
course on Software Validation and Verification. ThiscoSrseis 
now being taught by the University of Houston-Clear Lake in the 
new and approved Masters of Science degree in Software 
Engineering Sciences. The technical staff at Odyssey Research 
Associates in Itacha, New York uses Gries* book as a foundation 

the Penif matl } ei ? at;L< r s in support of security models and 

he Penelope Ada verification software engine [GUAS 901 . Odyssey 

Development^enter. deVe * OPment f ° r S ‘ *** 


nn» by s P ivey Presents the syntax of the z Schema [SPIV891 

Rele^nce'ManSfr^r? b0 °M S bein « ai “ ilar to the Ada Lnguagi' 
K«ff5 ence Ma ” ual - zt provides the concepts of Z for tool 

Is iot r sifficient? 0t * deSig " b °° k - The b °°* ls necessary but it 

Sommerville provides a terse but readable introduction to th* 
concepts of the Z schema [SOMM89]. Sommerville is not teaching 
discrete mathematics or Z in his book. I^the f i«t or i 
is book, there are numerical discrepancies between the text^nd 
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the Z templates. A sophisticated reader should be able to ignore 
these minor discrepancies. Several Z schema templates are 
included in this document. 

Reliable systems need to be composed of reliable components. 

This concept requires that a reuse paradigm be established to 
incorporate known reliable components with all associated design 
knowledge and assurances. The Fifth International Workshop on 
Software Specification and Design was held in Pittsburgh during 
May 1989. Several papers at this workshop relate to the 
pragmatic use of formal methods. 

The paper by London presents the use of the Z schema to specify 
two reusable components and their interfaces [LOND89]. Smalltalk 
was the language used by the investigators. 

Another paper proposed that software development may be able to 
use an analogy to the chemical engineering design process 
[D’IP89]. D'Ippolito writes "Chemical engineers are not taught 
to design polypropylene plants; they are taught the unit 
operations and the objects that provide them ..." . The reader 
can interpret this idea as composable design using objects and 
their defined interfaces. 

Mary Shaw of the Software Engineering Institute presented another 
paper that proposes that higher level abstractions are necessary 
to compose systems from subsystems [SHAW89]. Once again there 
seems to be a theme that reliable systems are composed of 
reliable components. 

The IEEE used formal methods as a theme for their September 1990 
issues of Computer, Software, and Transactions on Software 
Engineering. The Z schema is well represented in all three 
publications. Additional articles that have not been cited 
elsewhere in this reprot are [GERH90A], [HALL90], and [WING90]. 

X. Local Symposia and Tutorials 

The University of Houston-Clear Lake hosted a Software 
Engineering Symposium on November 7 & 8, 1990. The following 
tutorials were presented: 

Object Oriented Requirement Analysis 

Ed Berard, Berard Software Engineering Inc. [BERD90] 

Software Reuse 

Will Tracz, IBM System Integration Division [TRAC90 ] 

Software Safety 

Nancy Leveson, University of California, Irvine [LEVE90] 
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Applying Formal Methods by Hand 

John McHugh, Computational Logic Inc. [McHU90] 


Speakers included presentations by the Software Engineering 
Institute (SEI) , the Software Productivity Consortium (SPC) , and 
the Microelectronics and Computer Technology Corporation (MCC) . 
Susan gerhart of MCC provided a review of formal methods with an 
emphasis on the standards effort that is occurring in the United 
Kingdom [GERH90B] . The tutorials and presentations exhibited a 
variety of approaches to produce reliable software. The theme 
seems to be objects and formal mathematical support for 
specifying objects. 

During 90-91, UHCL and CSC are supporting a seminar series in 
Information Security, Integrity, and Safety (ISIS) . During the 
late spring or early fall it is planned to invite Odyssey 
Research Associates to present a tutorial on Formal Methods. Two 
design examples are used in the presentation: 

1) a flight control system 

2) secure Network Interface Unit component. 

During the summer of 1991, this writer will be teaching a 
graduate software engineering course on Formal Methods and 
Models. This course will provide a review of formal methods with 
an emphasis on a pragmatic application of the Z schema within a 
case study. 
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[PARN90] 

Paraas, David L. , John van Schouwen, and Shu Po Kwan. 
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Software Cost Reduction (SCR) work at the Naval 
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[SPIV89 ] 

Spivey, J. Michael. The Z Notation . New York: Prentice 

Hall. 1989. 
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The author provides a report on a case study using the 
Z notation to specify the kernel for a diagnostic X-ray 
machine. 
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[TRAC90] 

Tracz, Will. "Software Reuse." Tutorial . NASA/JSC UHCL 
1990 RICIS Symposium: Software Engineering . 7 November 

1990. Houston, Texas. 

[WING90] 

Wing, Jeannette. "A Specifier's Introduction to Formal 
Methods." Computer September 1990. pp. 8-24. 

A very readable summary of formal methods with an 
extensive reference list. 


[WOOD89 ] 

Woodcock, Jim and Martin Loomes. Software Engineering 
Mathematics . Reading: Addison-Wesley. 1989. 

The most readable book. The answers to the problems in 
Gries book act as a support mechanism for this book. A 
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specification of complex systems. SEI has chosen to 
investigate the path from Z to Annotated Ada (ANNA) to 
Ada. 


17 



Appendix A Comments on Notation 


To some software designers the Z notation may seem complex. This 
short essay is an attempt to put the notation in proper 
perspective. All engineers have taken calculus and have learned 
the notation of calculus. The calculus notation is then used in 
courses such as differential equations, dynamics, strength of 
materials, thermodynamics, etc. In addition all engineers have 
learned elements of matrix theory. The result is that most 
engineers would have not have any difficulty in understanding the 
notation of the state transition equation: 

X ' = Ax + Bu 

where ' has been used to represent the derivative with 
respect to time. Note that Word Perfect has placed a 
restriction on notation. A overline "dot" is the usual 
notation for the derivative with respect to time. The other 
symbols represent: 
x - state vector (n by 1) 

A - The plant: n by n matrix 

u - control vector (m by 1) 

B - control laws: (n by m matrix) 

The point is that an engineer routinely uses a high level 
notation to abstract from the fundamentals of the "delta" and 
scaler notation of calculus. Matrices are represented by single 
letters without explicit reference to their size. The size is 
implicit within the context of the equation. 

The notation for the Z language is based on discrete mathematics. 
The attached notation has been extracted from an article 
contained in the September issue of the IEEE Transactions on 
Software Engineering [Nara90]. The point is that if an 
individual claims to be a software engineer, then that individual 
needs to be familiar with the mathematical notation of software 
engineering. The Z schema provides a specification template 
using the notation of discrete mathematics. The notation is not 
unique to Z. 

[Nara90] Narayana, K.T. and Dharap, S. "Formal Specification of 
a Look Manager." IEEE Transactions on Software 
Engineering , vol 16 no. 9. September 1990. pp 1089- 
1103. 
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Z Notmios— Briefly 



“Is defined to be or same as/* 


A 

Logical conjunction. 

dom 

V' 

Logical disjunction. 

ran 

=> 

Logical implication. 


o 

Logical equivalence. 


V 

Universal quantification. 


3 

Existential quantification. 

/?* 

liM) 

The set of natural numbers. 

id X 


The set of integers. 

R- 

m , . n 

The set of natural numbers between m 



and n inclusive. 

R- 

= 

Set inclusion. 

R' 

r~ 

Strict set inclusion. 

i i 

u 

Set union. 


n 

Set intersection. 

S < R 

\ 

Set difference. 

S <S R 

6 

Set membership. 


{ }.° 

The empty set. 

R > T 

{rerm pred } 

The set of terms such that pred. 

R > T 

{ a . b) 

Ordered pair. 

R, ■£ R 

* 

The cardinality of a set. 

seq A 


Powerset. 

tts 

disjoint 

Pairwise disjoint. 

< > 

. A - B 

The set of total functions from A to B. 


A - B 

The set of partial functions from A to 



B. 

last s 

A ~ B 

The set of relations from A to S. 

front s 

(J - b) 

The singleton function (’’maplet”) 



which maps a to b. 

first s 

A 

Lambda abstraction. 

rest s 

f\X) 

Function / applied to x. 


fx 

Function / applied to x. 



Domain of. 

Range of. 

Relational (or functional) composition. 
Forward relational or functional com- 
position—/: g a gzf. 

Inverse of relation R. 

Identity function on the set X. 

Relation R composed with itself k 
times. 

Reflexive transitive closure of R . 
Nonreflexive transitve closure of R . 
Image-for R : A ~ B and_^ : (A L 

A ■ ) & { b : B \ ( 3a : A. a R b) } . 
Restriction of domain of R to S. 

Domain subtraction S^R±X\S< 
R where S f X ). 

Range restriction of R to T. 

Range subtraction of T. 

Relation overriding. 

Set of sequences drawn from A . 

Length of sequence s. 

Empty sequence. 

Concatenation of and s 2 . 

The last element of the sequence s. 

All but the last clement of the sequence 

s . 

First element of the sequence s. 

All but the first element of the sequence 

5 . 
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Schema Notvtiovs 


5 = [Dlpreds] is a schema definition D is a set ot 
declarations, preds are a set of first order formulas on the 
variables of D. The set constitutes a conjunctive first or- 
der formula. 

In the graphical notation, a schema has a name 5 with 
declarations D and predicate set pred and is written 


- S 

| D 

| pred y 
predy 

I pred n 


Schema name and the predicate part are optional 
Schema names usually designate operations. Components 
of a schema can be projected using the component names. 
pred S defines the predicate part of the schema 5. 

I ) Combinators on Schemas: A schema can be in- 
cluded in another. The resulting schema contains the union 
of the declarations and conjunction of the predicate parts 


SIP 
S: D 

' S[ new /old ] 


i s: 

-s 

i ■ 

| S A T 
S v T 


Schema S with P conjoined to the 
predicate part. 

Schema S wuh the declarations D 
merged with those of S. 

Renaming components, the name 
old in schema S is renamed to 
new every where it appears. 

Schema S with all names quoted 

Schema S with the predicate pan 
negated. 

Schema formed by the merging of 
declarations and the conjoining 
predicate pans of S and T 

Schema formed by the merging of 
declarations and the drsjoining 
of predicate pans ot 5 and T. 


pre 5 

Precondition: All the state after the 
dashed variables and outputs are 
hidden. 

post S 

Postcondition: All the state com- 
ponents undashed variables and 
the inputs are hidden from the 
predicate part. 

S •£ T 

Schema overriding = S A -* pre T 
v T. 

S ; r • 

Schema Composition: Schema 

formed when the final states of S 
become the initial states of T: in 
such composition, the base 
names of the dashed identifiers 
in S and the matching undashed 
identifiers in T are renamed and 
existentially quantified in the 
predicate part. 

2) Conventions : The following conventions are used 

for variables and predicates in schemas which designate 
operations. 

undashed 

State before the operation. 

dashed 

State after the operation. 

ending in ? 

Inputs to the operation. 

ending in ! 

Outputs of operation. 

5 - T~ 

Schema formed by mergine dec- 


larations and taking pred S = 
pred T as the predicate part. 

S\ (f|. • • • . 

v„ ) Hiding: Schema formed by remov- 
ing declarations r,. • . r„ in 

5 and existentially quantifying 
the predicate pan of S with re- 
spect to those variables. 
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Appendix B Z Schema Templates 


These templates have been reproduced from [SOMM89]. They are 
shown to demonstrate how low level schemata can be incorporated 
into higher level schemata within a terse but readable format. 

The low level Container and Indicator schemata (objects) have 
been used in the definition of the Hopper schema. The expanded 
version of the Hopper schema is shown to exhibit the total 
definition that results from including the Container and 
Indicator signatures into the Hopper definition. 

The SafeFillHopper is a schema for a modified fill operation. 

The delta on the Hopper means that this operation will change the 
state of the Hopper. The OverFillHopper schema is another 
example of an operation. The FillHopperOP has a predicate that 
provides an error check on the fill operation. 

[SOMM89] 

Sommerville, Ian. Software Engineering. Third Edition . 
Wokingham: Addison-Wesley, 1989. 
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Container 

contents: N 
capacity: N 


contents <= capacity 


Schema name 

Schema signature 


Schema predicate 




_ Indicator 

light: {off,on} 
reading: N 
danger: n 

light = on <=> reading <= danger 


The specification of an indicator. 
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Hopper 

Container 

Indicator 

reading = contents 
capacity = 5000 
danger = 50 


The specification of a hopper. 


Hopper 


rr — 

contents: N 
capacity: N 
reading: N 
danger N 
light:(off,on) 

1 

contents <= capacity 


light =on<=>reading<=danger 


reading = contents 


capacity = 5000 


danger = 50 

1 


The expanded specification of a hopper. 
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^SafeFillHopper. 


1 


Hopper 
amount?: N 

contents + amount? <= capacity 

contents' = contents + amount? 
I 

The specification of hopper fill operation avoiding overflow. 


OverfillHoppen 

A Hopper 
amount?: N 
r! = seq CHAR 


capacity < contents + amount? 
contents = contents' 
r! = "Hopper overflow" 

I 


The specification of the hopper overflowing. 


FillHopperOP 

SafeFillHopper v Overfill Hopper 


The specification of the hopper filling with error check. 
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